Field of the Invention
The invention relates to the provision of information in handling the decrypting of an asset having content protection associated therewith in order to authenticate access to the asset.
Description of the Related Art
The common encryption (CENC) protection scheme specifies standard encryption and key mapping methods that can be utilized by one or more digital-rights management (DRM) systems to enable decryption of an asset, such as a video file, using different DRM systems such as PlayReady, Marlin, Widevine or other encryption protocols supporting the CENC scheme.
The scheme operates by defining a common format for the encryption-related metadata necessary to decrypt the protected streams, yet leaves the details of rights mappings, key acquisition and storage, DRM compliance rules, etc., up to the specific DRM system or systems supporting the CENC scheme.
The CENC standard specifies three core elements:                1. The encryption algorithm used.        In particular CENC requires the use of the Advanced Encryption Standard, Federal Information Processing Standards Publication 197, FIPS-197 published by the United States National Institute of Standards and Technology (NIST) using 128-bit keys in Counter Mode (AES-CTR), as specified in “Recommendation of Block Cipher Modes of Operation”, NIST, NIST Special Publication 800-38A.        2. How to signal in the asset file that the file itself is encrypted.        3. Where to store the encryption related metadata necessary to decrypt the protected asset file.        
More precisely, the encryption related metadata necessary to decrypt the protected files or streams consists in turn of at least the following elements:                1. Protection System Specific Data.        This data is opaque to the CENC Common Encryption Scheme. This gives protection systems a place to store their own data using a common mechanism. This data is contained in the Protection System Specific Header (PSSH) Box.        2. Common encryption information for a media track, group of samples or individual samples.        These include default values for the key identifier (KeyID), initialization vector size, and encryption flag.        
An asset encrypted according to the CENC scheme may contain more than one PSSH header, e.g. one for each DRM system that is planned to be used for decrypting the asset. For instance, when the asset is encrypted, it is possible to include a PSSH header for PlayReady and a PSSH header for Widevine: in this way the same asset can be equally decrypted when it is received either by a PlayReady or by a Widevine DRM system.
This flexibility can be, for instance, exploited by a video player running in a client device such as a tablet, a laptop or a SmartTV for deciding at the time of decryption which DRM system to use based on criteria such as availability of DRM systems on the specific client device (e.g., a client device could support only a well-defined DRM system such as PlayReady) or, in the case more than one DRM system is available, on DRM costs (e.g., one DRM system being cheaper than another DRM system).
A video player must send a license request to a license server which includes information about which video the license request refers to. In a CENC enabled DRM system, the PSSH header is the data structure that is included in the license request and that will be used by the license server to extract the information it requires to process the request.
There are two different identifiers that are normally used to identify a video:                1. KeyID        This is the public part of encryption secrets used to encrypt the video (in the AES—advanced encryption standard—algorithm the encryption key is also used to decrypt the video).        2. ContentID        This is the identifier that uniquely identifies a video asset.        
The two may differ, for instance, in the case different segments of the same video asset have been encrypted using different encryptions keys.
Different DRM systems use either one or the other or both to extract from an encryption keys store a secret part of an encryption key that is then included in the DRM license that is eventually sent back to the video player.
For instance, PlayReady uses the KeyID value to extract from the key store the secret part of an encryption key. Widevine uses the ContentID for the same purpose.
The PSSH header for different DRM technologies only include the piece of information they need. Thus a PlayReady PSSH header contains the KeyID but not the ContentID, and a Widevine PSSH header contains both the KeyID and the ContentID.
The majority of current services are based on SmoothStreaming with PlayReady content protection (HSS/PR).
However some browsers, such as Chrome, do not provide support for PlayReady. At present, Chrome only supports assets which are in the MPEG-DASH format protected with Widevine (according to the common encryption scheme). However existing OTT (over-the-top) content services have a large catalogue of on-demand assets based on SmoothStreaming with PlayReady content protection.
In some situations it may happen that the encrypted video received in a video player contains PSSH headers for DRM systems that are not supported in the client device. For instance, it may contain the PSSH header for PlayReady but not for Widevine whilst the client device only supports Widevine. In this case, a basic implementation of a video player will not play the video because the client device does not have the necessary information required to engage the correct DRM system.
The authentication procedure refers to the procedure by which a user device obtains a license to allow content to be accessed (e.g. for a video to be played). In some situations the authentication procedure may be adjusted if additional information can be taken into account in the authentication procedure, than just the information which is associated with a given content protection format used by a received asset.
It is an aim of the invention to provide an improvement which addresses one or more of the above-stated problems.